Security-JAWS 第31回レポート #secjaws #secjaws31 #jawsug

Security-JAWS 第31回のレポートです。IAMとControl Towerでてんこ盛りでした！

#JAWS-UG

#セキュリティ

#レポート

#AWS

臼田佳祐

2023.11.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

Security JAWS 第29回が開催されましたのでレポート致します。

Security-JAWS【第31回】勉強会 2023年11月15日(水) - Security-JAWS | Doorkeeper

動画

レポート

Session1: 本番環境にあった危険なIAMをチーム全員で安全なIAM Roleに切り替えた話 eForce株式会社開発部 Rinchokuさん

実際に起きた事件の供養のためにきました
今年の6月からeForce株式会社で努めている
- インフラ周りは比較的最近触り始めた
当時の組織体制・本番環境
- アプリケーションチームとインフラチームが別れていた
  - アプリから要望をもらってインフラが構築して渡す感じ
  - 社内委託みたい
  - 結構分断されていた
- 当時の本番環境
  - Web: EC2
  - バッチ: ECS on Fargate
  - RDS
  - DynamoDB
  - S3
IAM Roleへ切り替えるきっかけになった出来事
- Slackに大量のエラーログが流れ始めた
- 数分で100件とか
- 17次頃から
- DynamoDBにアクセスができない
- 重なる営業への問い合わせ
- 何が起きていたか
  - アクセスキーでリソースにアクセスしていた
  - DynamoDB用のアクセスキーが無効化されている
  - 2017年に作られた長く使われているシステム
  - アクセス対象毎にアクセスキーが別れていた
  - ECS on Fargateのアクセスキーで、Adminがついていて、漏洩して攻撃者に操作された
- アクセスキー + Admin権限がついていた理由
  - アプリは今までアクセスキーを用いる開発をしていた
  - ECS on Fargateは途中から導入した技術
    - 2022年ぐらいから入れた
    - 初期設定や検証も含めてインフラがやっていて、とりあえずAdmin権限がついていた
    - アプリ側はAWS周りの設定は基本インフラに任せていた
    - アプリ側がAWSの知識をあまり持っていない
      - アクセスキーを使っていても違和感を感じていない
    - インフラ側も渡してから確認していない
Role切り替え
- 切り替えに向けて
  - 一時的にECS on Fartateを停止
  - サービスが利用しているAWSリソースの洗い出し
    - アクセス方法及びPolicyの洗い出し
    - アタッチするPolicyの整理
  - 本番適用までの不正利用監視方法の算出
  - 今回はリソースの洗い出しにフォーカスする
- AWSリソースの洗い出し
  - アプリとインフラで共同で7ステップで実行した
  - (アプリ・インフラ)利用しているAWSリソースの確認
  - (アプリ)関係図の整理
  - (インフラ)各AWSリソースが利用しているIAM User/Role/Policyの確認
  - (アプリ・インフラ)変更後のRoleの整理
  - (アプリ)最低限必要なPolicyの確認
  - (インフラ)IAMの設定
  - (アプリ・インフラ)動作確認・反映
  - 最低限必要なPolicyの確認について深掘り
- 最低限なPolicyに向けて
  - 今回のシステムはGet/Postとシンプルな操作だけ
    - AWSの各リソースページで必要な権限をリストアップ
  - IaCは少しずつ進めていた
  - マネジメントコンソールのものは残す
  - 分かりづらいポイント
    - AWSのカスタムPolicyを作るときに対象AWSリソースのPolicy一覧がどこにあるかわからない
    - Policyが色々ありすぎてどこまで必要かわからない
    - 実は裏で使っている権限がある
- IAMのベストプラクティス
  - 色々書いてある
  - 最小特権アクセス許可の適用
    - タスクの実行に必要なアクセス許可のみを付与
    - 必要なアクセス許可を検討しながら大まかなアクセス許可から始めるとよい
      - これを意識するといい
      - とはいえこれも簡単ではない
- 個人的なおすすめ
  - AWSのマネージドポリシーを見つける
    - FullAccessだと対象リソースに絞り込むにはあまり使えない
      - *になっていると細かいポリシーは把握できない
    - ただ関連リソースを見つけるのには有効
      - 連携するサービスとかはわかる
  - マネージドポリシーで許可しているPolicyを確認
  - 不要と思われるPolicyを取り除く
  - エラーが出たら対象Policyを付与する
- 構成図上でどこに何をつけるかマッピングした
- 切り替えの流れ
  - ステージング環境にてアクセスキーを用いたままRoleをアタッチ
  - ステージング環境のアクセスキーの記述を削除してデプロイ
  - 上記を本番環境で同様に実施
最後に
- 自分たちが利用する周辺サービスの知識はキャッチアップしよう
  - そもそも知らないことは違和感に感じない
- Securityはアプリ・インフラ領分は関係ない
- 失敗ややらかしたものは貴重な情報なので怖がらず共有しよう

感想

貴重な体験の共有でしたね。セキュリティはみんなの責任と考えて取り組んでいきたいですね！

Session2: IAM Access Analyzer を利用した最小権限への旅株式会社大和総研粟ケ窪康平さん

自己紹介
- オンプレネットワークの設計をやっていたがAWSの資格を全て取得して引退
- 普段はControl Towerなどを使っている
話さないこと
- 最小権限は何かという哲学的な問い
- IAMポリシー/ロールの基本
IAM Access Analyzerとは
- リソースポリシーを分析して証明可能なセキュリティを提供することで最小特権のアクセス権限を簡単に実装できるようにするとともに、意図しないパブリックアクセスまたはクロスアカウントアクセスを特定する
IAM Access Analyzerの進化
- 定期的に機能拡張が繰り返されている
- 2019年のre:Inventで発表
できること
- 権限管理ライフサイクルのあらゆるステージを支える各種機能を提供
- 権限の設定、権限の確認、権限の修正のステージごとに便利に使える
- 権限の設定
  - 権限を正しく設定するための機能
  - policy validation
  - ポリシー設定画面の下についているチェック機能
  - 4つのカテゴリ
    - Security
      - 過度に広いアクセス権限を指摘
    - Errors
      - 文法的な誤りを指摘
    - Warnings
      - ベストプラクティスに沿っていない
    - Suggestions
      - 改善のための推奨事項
- 権限の確認
  - 過剰な権限が設定されていないか確認する
  - external access findings
  - 外部エンティティと共有されている組織とアカウントのリソースを識別
  - 例えば外部公開されているS3バケットを一覧で出す
- 権限の修正
  - 過剰な権限を削除し洗練させるための機能
  - IAM Last accessed information
    - 厳密にはAccess Advisorの機能
    - 最後にアクセスしたAPIを追随してくれる
    - 許可されているけど使われていないものを洗い出せる
    - サービスレベルだけでなくアクションレベルでも一覧を出せる
    - アクセスされていないアクションでフィルタできる
  - policy generation
    - CloudTrailのログを分析してポリシー生成を支援する
    - 一部はリソースが入っていなかったりするので調整が必要
- 素晴らしいサービスですね
- しかし銀の弾丸ではない
悩ましいところ
- 公開アクセスの検知結果が多すぎてどこからやればいいかわからない
  - 環境の規模が大きいほど多数のノイズが含まれる
    - S3が公開されていていいか
    - フェデレーションユーザーがいっぱいいる
    - 謎のエラー
    - AWSから検出結果の優先順位をつけるための指針が出ている
      - パブリックアクセスを確認
        
        S3やEBSスナップショットの公開などが検知される
        
        意図した公開ならアーカイブする
        
        アーカイブルールを作って出ないようにできる
        
        意図していない場合には速やかに是正する
        
        PrinsipalOrgIDなどで識別する
      - 謎の権限エラーを削除
        
        リソース側で明示的な拒否を行っているとリソースメタデータが読み取れなくてエラーになる
        
        拒否条件にサービスにリンクされたロールを追加する
      - 既知のIDプロバイダーをフィルター
        
        IAM Identity Center等のIdPをプリンシパルとして許可する信頼ポリシーを持つロールを検知してしまう
        
        Control Towerを展開した時にたくさん検知される
        
        IAM Identity Centerの予約パスを使用してアーカイブルールを作成する
        
        Federated Userをsaml-provider/AWSSSO
        
        Resourceをaws-reserved/sso.amazonaws.com
      - 信頼できるクロスアカウントアクセスをフィルター
        
        リソースベースポリシーが信頼ゾーン害からのクロスアカウントアクセスを許可している場合に検知する
- コードで展開するIAMリソースの事前検証ができない
  - IAM Policy Validator for AWS CloudFormationの利用
  - CI/CDパイプラインに組み込む
  - ワークショップがある
最小権限の旅の始め方
- IAM Access Analyzerとセキュリティ成熟度モデル
- 最初にまずIAM Access Analyzerを有効化する
- 次にEfficientで色々ある
  - レビュー
  - 意図しないアクセスの審査
  - Advisorの利用
  - Analyzerを利用したポリシー生成
- Optimized
  - IAMパイプライン
  - 本当に成熟した組織になったらこれをやっていくといい

感想

IAM Access Analyzerは便利に使えるサービスなのでとりあえず有効化したほうがいいですね！ガリガリ使っていきましょう！

Session3: IAMの権限付与状態を可視化して権限最小化してみたパロアルトネットワークス株式会社技術本部Prisma Cloud 西田和弘さん

IAM権限付与の課題
- パロアルトで調査した結果
  - ユーザーIDの99%が権限付与過剰
  - 53%のクライアントが弱いパスワードを許容
  - 44%のクラウドアカウントがパスワードの再利用を許容
- IAMに関する大規模調査結果
  - AWS管理ポリシーの利用が43%
  - IAM管理ポリシーのアクセス許可付与数はカスタマー管理ポリシーの2.8倍多い
  - IAM管理ポリシーのアクセス権限使用率はカスタマー管理ポリシーより3.2倍低い
  - AdministratorAccessが頻繁に使われている
- 権限管理が複雑で難しい
  - とりあえずAdministratorAccessを付与してしまう
  - ガートナーでは2023年までにクラウドセキュリティ事案の75%が権限不備になるだろうと予測されている
- 危険な権限付与
  - IAMだけ気にするわけではなく、EC2やコンテナなど様々なリソースに対しても気をつける必要がある
権限付与の可視化
- チャートによる直感的な把握
- Prisma Cloud IAM Securityを使うといい
  - 可視化と最小化ができる
  - CSPMやIAM、CloudTrailの情報を収集して動作する
- IAM Policyがいろんな経路でアタッチされるため可視化が難しい
- 独自のクエリ言語でチャートで可視化できる
  - Source / Granters / Destinations
  - 3つのセクションで表示
  - 付与元のユーザー / 権限付与者 / 付与先リソース
- Sourceの種類
  - リソースにアクセスできるAWSアカウント
  - IAMユーザーやIdPのユーザー
  - パブリックアクセス
  - EC2/Lambdaなどのリソース
- Grantersの種類
  - Group
  - Role
  - Direct
  - Resource
    - リソース上での権限付与
- Destinationsの種類
  - サービスの種別
  - リソース名
  - 表ビューで深掘りできる
- どんなクエリができるか
  - パブリックアクセスできるもの
  - 任意のS3にアクセスできるできるもの
  - IAMユーザーに付与されたものはなにか
  - AdministratorAccessを許可しているグループ、ロールはなにか
  - インラインポリシーがアタッチされているユーザー
  - 使用していない権限の検出
ポリシー監査による権限最小化の仕組み
- 付与されるべきではないポリシーを検査
- 一定期間学習
- 使わない権限を外す提案をして自動修正もできる
- コンセプト
  - IAMに関する権限は管理者以外はいらない
  - 不用意なパブリックアクセスを禁止する
  - ワイルドカードを使わない
- 検査対象
  - IAM管理者権限を持つリソースの監視
  - リソースのパブリックアクセスの監視
  - 一定期間使用していない過剰な権限
- アラートが出るのでこれを修正していく
- 最小化の例
  - prismaでは必要でないものをDenyにしていく
  - 既存のものを外さなくていい
  - 万が一問題があっても、直しやすい
- 使用履歴に基づいた最小化
  - CLIで最小権限を反映するためのコマンドが発行される

感想

最小権限は一筋縄ではいかないので、ツールもうまく使っていきたいですね。AWS Security HubやIAM Access Analyzerが最初の検討対象になりますが、Prisma Cloudも便利なツールなのでぜひ検討してみてください。

Session4: S3の情報漏洩からデータを守るには？CloudFormationで作るS3標準テンプレートのご紹介株式会社セゾン情報システムズ坪井千春さん

自己紹介
- 最近はお客様先でCCoEしている
- 直近6年くらいAWSをやっている
S3からの情報漏洩の事例
- 意図せず公開状態となる事例が耐えない
- 2022年7月
  - 最大3TBの個人情報流出
  - S3バケットが公開されていた
- 2022年6月
  - 国内
  - 622人の個人情報
  - S3にバックアップを取っていたが公開されていた
- 最近の統計
  - Misconfigurationは19%の割合
  - OWASP TOP10でも8位
  - なぜなのか？
    - S3は簡単に利用できて多機能なので設定ミスが起こりやすいのでは
  - 2023年4月から全ての作成方法でS3パブリックアクセスブロック有効、ACL無効がデフォルトになった
- 対策
  - AWS Config
  - Amazon GaurdDuty
  - Amazon Macie
リソースベースポリシーの重要性
- リソースベースポリシーとは
- IAMポリシーとして設定できるもの
  - アイデンティティベースポリシー
    - エンティティが行うことができる操作の制御
  - リソースベースポリシー
    - リソース側でどのようなアクションができるか
    - S3の場合はバケットポリシーがこれに当たる
- できること
  - 対象のリソースに対するアクセス制御が可能
  - クロスアカウントを許可
  - 条件を付与して詳細な管理ができる
- データ境界の確立
  - リソースベースポリシーはアクセスコントロールにおける重要機能
  - VPC Endpointのリソースベースポリシー(エンドポイントポリシー)でほかアカウントへのアクセスを明示拒否することで情報持ち出しを禁止
  - S3のリソースベースポリシー(バケットポリシー)によりほかネットワークからのアクセス不可
S3標準テンプレートのご紹介
- テンプレートの概要
- 最低限のセキュリティを全システムに適用するテンプレート
- セキュアなS3を展開するためのベストプラクティスを反映したもの
- CloudFormationで簡単に使えるようにした
- 機能
  - アクセスコントロール
    - リソースベースポリシーで明確なアクセス制御
      - パブリックアクセスブロック
      - VPCE限定
      - IAM Role限定
    - 暗黙的な拒否を使わないポリシー
    - AdministratorAccessがついたロールもブロックする
    - 権限を3つに分割
      - Adminはバケット自体に対する管理権限
        
        オブジェクトには読み書きできない
      - Writable
        
        オブジェクトの管理権限
        
        設定は書き込みできない
      - ReadOnly
        
        オブジェクト参照のみ
        
        バケットの設定や書き込みはできない
    - リソースベースポリシーで記載できないアクションを除く81件に対し各ロールに権限を定義
    - ポリシー概要
      - 想定外のアクションを全拒否
      - それぞれのロールの許可拒否を入れていく
        
        同じ条件の許可とNotActionの拒否を入れる
      - StringNotEqualsやNotActionを駆使する
  - 暗号化の強制
    - 全ての暗号化を強制しKMSの設定もセットで行う
      - HTTPSのみ
      - TLS1.2以上のみ
      - SSE-KMSのAWS Managed KeyかCustomer Managed Key
      - こちらもリソースベールポリシーで制限
  - バージョニング/StorageLens
    - バージョニングとライフサイクルポリシー
    - 不完全なマルチパートアップロード削除
    - StrageLensをパラメーターで作れるようにしている
課題
- 開発環境での利用しやすさ
  - オブジェクトの一覧表示はAdminにも付与して良いのではないか
  - Readonlyは不要なケースもあるのでオプションに
- 使い始めの学習コスト
  - S3標準テンプレートが900行
    - コメントの充実化
  - パラメータが11項目
    - 必須項目を減らす
- 利用範囲
  - 用途によっては採用できない場合がある
  - ALBのアクセスログの場合にはロール指定やSES-KMSが利用できない
  - 用途専用のテンプレートを用いる
まとめ
- S3かrなお情報漏洩は深刻なリスク
- リソースベースポリシーを使って適切にアクセスコントロールしよう
- 標準テンプレートをつくるといいよ

感想

情報漏洩しないための組織内の仕組みづくりは大事ですね。VPC Endpointとバケットポリシーの組み合わせで厳密に管理できるので、重要なデータが保持される場合には参考にしたいですね。

Session5: AWS Control Towerを2年弱運用して得たエッセンスと展望みずほリサーチ&テクノロジーズ株式会社先端技術研究部小坂　洋祐さん

社内プラットフォームの概要
- 2つのプラットフォームがある
- みずほ銀行向け
- お客様(外部)向け
- 今回は外部向けの話
- プロダクトビジョン
  - 安心してAWSの有用性を発揮してプロジェクトオーナーなどが安心して使えるようにする
  - アカウント管理の中心としてAWS Control Towerを活用
AWS Control Towerの概要・活用
- できること
- ランディングゾーンに則ったアカウントの発行
- AWSのベストプラクティスに則った設定でアカウントを発行できる仕組み
- ログ集約
- Config Rulesの通知
- AWS IAM Identity Centerでシングルサインオン
  - 複数アカウントの切り替えも楽
コントロール適用
- コントロール(ガードレール)とは
  - 継続的なガバナンスを提供するルール
  - 予防、検知、プロアクティブがある
- AWSアカウント一括で反映できる
- 必須のコントロール例
  - ランディングゾーンで作成したリソースの変更や削除の制限など
- 強く推奨のコントロール
  - ルートユーザーのアクセスキーの作成を許可しない
- プロアクティブとは
  - CloudFormationフックを利用して実現する
  - CloudFormationの展開前に非準拠のものをブロックする
  - 今回は利用していない
ランディングゾーンバージョンアップ時の対応
- v2.7から利用開始している
- 現在はv3.2で5回アップデートしてきた
- 通常の更新
  - Control Towerのランディングゾーン設定からバージョンを選んで上げる
  - その後OU毎に更新が必要
- 起きたこと
  - v3.0の更新でCloudTrailがアカウントベースから組織ベースの証跡に変更された
  - これまではCloudTrailの証跡が各アカウントのCloudWatch Logsに入っていた
  - バージョンアップしたらマスターアカウントに集約された
  - 結果Security HubのCIS3.1-3.15がチェックできなくなった
  - ログが出なくなったため
- 対応
  - 各アカウントにCIS確認用の証跡を追加した
- 5回中大きな変更は1回のみ
- バージョンアップしないことはないので、検証用Control Towerアカウントを用意しよう
アップデートによる改善
- S3バケットのキーを指定可能になった
  - 前はSSE-S3になっていた
  - マネジメントアカウントのKMS keyを利用できるようになった
- ログS3バケットの保持ポリシーをカスタマイズできるようになった
  - 保管期限が1年で固定だった
  - ログ用とアクセスログ用でそれぞれ期間を指定できるようになった
- Account Factoryが5つまで同時実行できるようになった
  - これまでは並列でアカウント作成できなかった
  - 30-40分まって1回ずつやる必要があった
- 大阪リージョン対応した
  - 大阪リージョンにもランディングゾーンが適用できるようになった
まとめ
- メリット
  - Control Towerの活用によっていろいろできる
  - 料金は直接かからない
- デメリット
  - 定期更新が必要
    - 内容をよく確認する必要がある
  - カスタマイズ性は高くないので要件に合うか検証が必要
  - 独自の制限などは別途必要
- おわりに
  - Control Towerは今後必須のサービスになっていくのではないか

感想

Control Towerは便利なので、要件に合うか検証して使っていきたいですね。検証用のControl Towerは必須です！

Session6: BLEA for FSI のusecaseから始める金融レベルのセキュリティ石倉幸さん

BLEAって何？？
- Baseline Environment on AWSの略
- CDKのコード
- for FSIって何？？
- for Financial Services Instituteの略
- FICSの安全対策基準準拠のために追加されている
- Well-ArchitectedフレームワークにFISC用のLensがある
- そしてそれを実装するためにBLEA for FSIがある
ユースケース1: オープンAPI
- オープンAPIとは
  - 3rdパーティからアクセス可能なAPI
  - 金融機関と外部企業が安全にデータをやり取りすることで協業しシナジーを生み出す
  - 全銀による仕組みづくりが2016年から開始している
  - 家計簿サービスやQRコード決済サービスなど広く普及している
- オープンAPI以前ではスクレイピングしていた
  - Fintech企業は顧客からパスワードを預かり顧客に成り代わってアクセスしていた
  - リスクがある
- オープンAPIではFintech企業はAPI契約をする
  - 顧客はパスワードを提供しなくていい
- 4種類のリファレンスがある
  - ベーシックAPI
    - 主にエンドユーザーからの参照
  - 金融グレードAPI
    - Fintech企業など外部企業からのアクセスを想定
- ベーシックAPIのアーキテクチャ
- 金融グレードAPIのアーキテクチャ
  - mTLSを利用する
  - 認可サーバがOKならトークン発行
  - トークンを利用してAPI Gatewayへ
  - Lambda Authorizerでトークン検証
- リファレンスアーキテクチャがあることでそれぞれの違いが明瞭になる
  - 相互認証が必要かどうかで変わっている
ユースケース2: 勘定系
- 勘定系とは
  - 銀行業務の中核を担うシステム
  - 入出金や資産管理など
- 勘定系のアーキテクチャ
  - ECSを利用している
  - メインDBがAuroraでステート管理にDynamoDB
- セキュリティ面の実務対策
  - FISCとのマッピングも紹介してある
    - DirectConnectを用いた閉域網の利用
      - 内部もTLSを利用する
    - ALBへのWAFの適用
      - AWSマネージドルールが使われていた
      - コアルールやSQLiなど5つが付いていた
サマリ
- リスクを許容範囲内まで下げるのがセキュリティ対策
- ただ対応する労力は高い
- そして売上には直結しない
- これに沿っていればセキュリティも業界ルールも大丈夫な安心感
- 最高！

感想

BLEA for FSIはよくまとまっているので、読み物としても参考になりますね。最高！

Session7: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

[Anonymous]社内システムでsecurity hubを導入したいのですが、上司からは予測コストを提示してほしいと言われています。これに対し、security hubの30日間無料トライアルでコストを予測しようと考えているものの、security hub はconfigruleによる料金が意外と大きいと聞いており、security hub によるconfig rule利用も無料トライアルの対象なのかが気になっています。もしご存じでしたらご教示下さい。

セキュリティチェック部分のConfig RulesはSecurity Hubの料金なので無料枠の範囲内です
参考としては、ミニマムなAWS環境で全リージョンでSecurity Hubを有効化すると月額$15程度
結局は実環境でなるべく早く試すといい
すぐに辞められるのもクラウドのメリット

[Security Hub芸人]メンバーアカウントからrootを取り上げているのでmfa 設定しないという運用にひと言お願いします

インターネットの先にあるサービスでMFAをしないことは絶対にない
やりたくない人はAWS使わせない
デバイスがないなら配ったらいい

[Anonymous]aws導入に向けてセキュリティの勘所をつけてクラウド移行を行っていきたいです。

オンプレから移行するなら、ネットワークを気にする必要がある
- ネットワーク管理者との境目がなくなってくる
- うっかり穴を開けてしまう
- クラウドと言っても中身は物理なのでインフラなどの技術の知識が必要
頼れる人に頼った方がいい
- GuardDutyやSecurity Hubは使ってくれ
オンプレミスで持っていたセキュリティ対策をそのままクラウドに持っていくとやられる
- アタックサーフェイスが増える
- ログ取得するとかやれることをやっていく